Conversation
leongdl
requested changes
Sep 11, 2026
Existing boundary fixtures use literal job names, so an implementation that checks the literal at decode but mishandles the resolved value at job creation still passes the suite. These fixtures set the job name via a bare {{Param.N}} substitution so the limit is enforced after the format string has been resolved: 129 chars with no extension is rejected, 512 chars with FEATURE_BUNDLE_1 is accepted, and 513 chars is rejected.
The valid 512-char fixture asserts the task's output (the resolved name length), because the runner only checks expected output for valid job tests; without it a job-creation failure would still be reported as a pass.
Signed-off-by: Yongzhi Wei <276409147+wyongzhi@users.noreply.github.com>
wyongzhi
force-pushed
the
fb1-resolved-job-name-length-fixtures
branch
from
September 11, 2026 22:51
e9d8b8e to
8fea26d
Compare
Collaborator
Author
|
The |
wyongzhi
marked this pull request as ready for review
September 11, 2026 23:15
leongdl
approved these changes
Sep 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds three job-execution conformance fixtures that make the job name cross a length boundary through job-parameter substitution:
{{Param.N}}resolves to2023-09/base/jobs/1.1.1--job-name-too-long-substitution.invalid.test.yaml2023-09/FEATURE_BUNDLE_1/jobs/1.1.1--job-name-512-chars-substitution.test.yaml2023-09/FEATURE_BUNDLE_1/jobs/1.1.1--job-name-513-chars-substitution.invalid.test.yamlWhy
The Template Schemas define the
JobNamelimit as "128 characters, after the format string has been resolved. 512 characters, after the format string has been resolved if using theFEATURE_BUNDLE_1extension" (§1.1.1). Every existing length-boundary fixture (1.1.1--max-length.yaml,1.1.1--too-long.invalid.test.yaml,1.1.1--job-name-512-chars.yaml,1.1.1--job-name-513-chars.invalid.yaml,1.1.1--job-name-without-extension.invalid.test.yaml) uses a literal name, and every fixture whose name is a format string resolves to 30 characters or fewer. So an implementation that applies the limits to the template literal at decode time but mishandles the resolved value at job creation passes the suite today. These fixtures lock the "after the format string has been resolved" clause for both the base and the FEATURE_BUNDLE_1 limit. The template is short and decodes fine in every case; the outcome is decided only at job creation, which is what.invalid.testis for (README: "template passes static validation but the error only fires during evaluation").The name is a bare
{{Param.N}}so the resolved length equals the parameter length exactly; the long values are written as literalAruns, as in1.1.1--job-name-512-chars.yaml. The valid 512 fixture asserts the task's output (OUTPUT:512, the resolved name length): the runner only checksexpected.outputfor valid job tests, so without it a job-creation failure would be reported as a pass. Each fixture carries a header comment naming the spec section and the limit it pins. STRING parameter defaults are capped at 1024 characters, so none of the three values can fail at decode for a parameter-value reason.Testing
run_openjd_cli_tests.pywith openjd-cli 0.7.7 against the released openjd-model-for-python 0.11.11 (no companion fix): the 512 fixture fails withMissing expected output: OUTPUT:512and the run errorString should have at most 128 characters; the two.invalid.testfixtures pass. This is the gap the fixture exists to catch..invalid.testcases reject with "at most 128 characters" and "at most 512 characters", the 512 case creates, runs, and printsOUTPUT:512.Related
Companion fix in openjd-model-for-python: OpenJobDescription/openjd-model-for-python#362 (without it, the 512 fixture fails on the Python implementation; the Rust implementation already passes all three).
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.